home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
archiver
/
unix
/
unz50p1.zoo
/
VMS
/
VMS.notes
< prev
next >
Wrap
Text File
|
1992-05-24
|
14KB
|
310 lines
VMS Notes for UnZip 5.0
24 May 1992
The various VMS tweaks to UnZip 5.0 and ZipInfo 0.97 were tested on a
VAX 8600 running VMS 5.2 (and, later, VMS 5.4) and VAX C 3.0. Older
versions were also tested on a VAX 11/785.
To build UnZip (and its trusty sidekick, ZipInfo), just run one of the
included command files MAKE_UNZIP_VAXC.COM or MAKE_UNZIP_GCC.COM, either
decryption or non-decryption versions, depending on whether you have the
separate crypt.c module and whether you use VAX C or GNU C (for example,
"@make_unzip_vaxc"). By default, this creates shareable-image executables,
which are smaller and (supposedly) load faster than the normal type. They
also (supposedly) will be better able to take advantage of any bug fixes
or new capabilities that DEC might introduce, since the library code isn't
built into the executable. The shared executable is about a quarter the
size of the ordinary type in the case of UnZip.
[Btw, the VMS make utility "MMS" is not compatible enough with Unix make
to use the same makefile. Antonio Querubin, Jr., sent along an MMS makefile,
subsequently modified by Igor Mandrichenko. Read the comments at the top
of DESCRIP.MMS for more info. An alternate Unix-like makefile designed for
use with Todd Aven's MAKE/VMS is included, as well. Comments on where to
get MAKE/VMS are at the bottom of VMS Contents.]
UnZip is written to return the standard PK-type return codes (or error
codes, or exit codes, or whatever you want to call them). Unfortunately,
VMS insists on interpreting the codes in its own lovable way, and this
results in endearing commentary such as "access violation, error mask =
0005, PC = 00003afc" (or something like that) when you run UnZip with no
arguments. To avoid this I've added a special VMS_return() function which
either ignores the error codes (and exits with normal status) or interprets
them, prints a semi-informative message (enclosed in square [] brackets),
and then exits with a normal error status. I personally can't stand the
latter behavior, so by default the error codes are simply ignored. Tastes
vary, however, and some people may actually like semi-informative messages.
If you happen to be one of those people, you may enable the messages by
recompiling misc.c with RETURN_CODES defined. (This adds a block or two
to the executable size, though.) The syntax is as follows:
cc /def=(RETURN_CODES) misc
To use UnZip in the normal way, define a symbol "unzip" as follows:
unzip :== "$diskname:[directory]unzip.exe"
(substitute for "diskname" and "directory" as appropriate, and DON'T FORGET
THE `$'! It won't work if you omit that.) In general it's wise to stick
such assignments in your LOGIN.COM file and THEN forget about them. It is
no longer necessary to worry about the record type of the zipfile...er,
well, most of the time, anyway (see the Kermit section below).
Having done all this you are ready to roll. Use the unzip command in
the usual way; as with the Unix, OS/2 and MS-DOS versions, this one uses
'-' as a switch character. If nothing much happens when you do a directory
listing, for example, you're probably trying to specify a filename which
has uppercase letters in it...VMS thoughtfully converts everything on the
command line to lowercase, so even if you type:
unzip -v zipfile Makefile
what you get is:
unzip -v zipfile makefile
which, in my example here, doesn't match the contents of the zipfile.
This is relatively easy to circumvent by enclosing the filespec(s) in
quotes:
unzip -tq unzip401 "Makefile" "VMS*" *.c *.h
[This example also demonstrates the use of wildcards, which act like Unix
wildcards, not VMS ones. In other words, "VMS*" matches files VMSNOTES,
VMS_MAKE.COM, and VMSSHARE.OPT, whereas the normal VMS behavior would be
to match only the first file (since the others have extensions--ordinarily,
you would be required to specify "VMS*.*").]
Note that created files get whatever default permissions you've set, but
created directories additionally inherit the (possibly more restrictive)
permissions of the parent directory. And, of course, things probably won't
work too well if you don't have permission to write to whatever directory
into which you're trying to extract things. (That made sense; read it
again if you don't believe me.)
ZipInfo, by the way, is an amusing little utility which tells you all sorts
of amazingly useless information about zipfiles. Occasionally it's useful
to debug a problem with a corrupted zipfile (for example, we used it to
find a bug in PAK-created zipfiles, versions 2.5 and earlier). Feel free
to blow it away if you don't need it. It's about 30 blocks on my system,
and I find I actually prefer its listing format to that of UnZip now (hardly
surprising, since I wrote it :-) ). I also find it useful to use "ii"
rather than "zipinfo" as the symbol for zipinfo, since it's easier to type
than either "zipinfo" or "unzip -v", and it echoes the common Unix alias
"ll" for the similar style of directory listings. Oh, and the reason it's
still got a beta version number is that I haven't finished it yet--it would
be better with an automatic paging function, for example. Oh well.
RANDOM OTHER NOTES: (1) Igor Mandrichenko (leader of our fearless Russian
contingent) rewrote major portions of the VMS file-handling code, with
the result that UnZip is much smarter now about VMS file formats. For
full VMS compatibility (file attributes, ownership info, etc.), be sure
to use the -X option of Zip 1.6 and later. There are also some notes
at the end of this file from Hugh Schmidt and Mike Freeman which give
hints on how to save VMS attributes using Zip 1.0 and UnZip 4.1. Most of
the information is still valid, but the -X option is much easier if you
don't have to transfer the zipfiles to a Unix or PC system. (2) Zip 1.0
cannot handle any zipfile that isn't in stream-LF format, so you may need
to use Rahul Dhesi's BILF utility which is included with UnZip. It will
also be necessary for certain other special occasions, like when you've
forgotten to set the correct Kermit parameters while uploading a zipfile
(see Hugh Schmidt's note below for comments about Kermit, too).
Greg Roelofs
====================
From INFO-ZIP Digest (Wed, 6 Nov 1991), Volume 91, Issue 290
VMS attributes and PKZIP compatibility
VMS attributes restored! (2 msgs)
------------------------------
Date: Tue, 5 Nov 91 15:31 CDT
From: Hugh Schmidt <HUGH@macc.wisc.edu>
Subject: VMS attributes and PKZIP compatibility
Message-ID: <21110515313938@vms.macc.wisc.edu>
******************************************************
(1) *** Retaining VMS attributes - a proposed strategy ***
******************************************************
This is a proposed strategy for recovering VMS file attributes after
zip/unzip:
a) capture VMS file attributes: VMS ANALYZE/RMS/FDL/OUTPUT=fdlfile vmsfile.ext
b) compress files on VMS......: ZIP zipfile vmsfile.ext, fdlfile.fdl
c) uncompress files on VMS....: UNZIP zipfile vmsfile.ext, fdlfile.fdl
d) recover VMS file attributes: CONVERT/FDL=fdlfile.fdl vmsfile.ext vmsfile.ext
The wrinkle is that UNZIP creates files which are unreadable by CONVERT
despite a concerted effort to accomodate VMS file management system:
file_io.c, line 178: ...creat(filename,0, "rat=cr", "rfm=streamlf")
These files are unCONVERTABLE because they appear to VMS to contain
records with 512+ bytes. Poring over VMS manuals (Programming V-6A, VAX
C RTL Reference Manual) doesn't readily suggest better alternatives.
Experimentation with "rat=fix", etc. may help suppress the spurious
block-end delimeters.
****************************************************
(2) *** VMS ZIP and PKZIP compatibility using KERMIT ***
****************************************************
Many use Procomm's kermit to transfer zipped files between PC and VMS
VAX. The following VMS kermit settings make VMS-ZIP compatible with
PKZIP:
VMS kermit Procomm kermit